home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 370 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  11.0 KB

  1. Path: chronicle.mti.sgi.com!austern
  2. From: kanze@gabi.gabi-soft.fr (J. Kanze)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Are all Windows programs ill-formed?
  5. Date: 09 Feb 1996 09:12:58 PST
  6. Organization: GABI Software, Sarl.
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <KANZE.96Feb9165408@gabi.gabi-soft.fr>
  9. References: <AE5J83na99@qsar.chem.msu.su> <9602010236.26117@mulga.cs.mu.OZ.AU>
  10.     <9602021032.AA05302@lts.sel.alcatel.de> <4evp66$a58@mulga.cs.mu.OZ.AU>
  11. NNTP-Posting-Host: isolde.mti.sgi.com
  12. X-Original-Date: 09 Feb 1996 15:54:08 GMT
  13. In-Reply-To: fjh@munta.cs.mu.OZ.AU's message of 05 Feb 1996 09:24:05 PST
  14. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  15.     iQBVAwUBMRuAq0y4NqrwXLNJAQFq1AH/a2B42Q4HmmonFIAeugtk7SQQfMxTOGa3
  16.     0H/cAD1Cwh7CleqbavkBKP7713Gdd8oaK/XlwZgxHKtYZMiRXLpVxg==
  17.     =iJXP
  18. Originator: austern@isolde.mti.sgi.com
  19.  
  20. In article <4evp66$a58@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus
  21. Henderson) writes:
  22.  
  23. > James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
  24. > >fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
  25. > >
  26. > >|> "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
  27. > >
  28. > >|> The implementation is allowed to make the program work even if main() is
  29. > >|> not defined, so long as it issues a diagnostic.
  30. > >
  31. > >By a curious coincidence, this point has just been discussed in
  32. > >comp.std.c.  The concensus of the experts there was that the absense
  33. > >of main (or a non-conformant main) is simply undefined behavior: no
  34. > >diagnostic required.
  35. > If the comp.std.c experts are right, then I think that is a difference
  36. > between C++ and C, because the September 95 draft C++ standard makes it
  37. > pretty clear that a diagnostic is required.
  38. > | 3.6.1[basic.start.main]/1:
  39. > |    A program shall contain a global function called main, which is the
  40. > |    designated start of the program.
  41. > Here "shall" expresses a semantic requirement, and as 1.7 makes clear,
  42. > a diagnostic is required:
  43. > |   1.7  Processor compliance                           [intro.compliance]
  44. > | 
  45. > | 1 Every conforming C++ processor  shall,  within  its  resource  limits,
  46. > |   accept and correctly execute well-formed C++ programs, and shall issue
  47. > |   at least one diagnostic message when  presented  with  any  ill-formed
  48. > |   program  that contains a violation of any diagnosable semantic rule or
  49. > |   of any syntax rule, except as noted herein.
  50. > [...]
  51. > | 3 The set of "diagnosable semantic rules" consists of all semantic rules
  52. > |   in  this  International  Standard except for those rules containing an
  53. > |   explicit notation that "no diagnostic is required."
  54.  
  55. This would seem to be a difference.  In the C standard, there are never
  56. any explicit words that say a program must/shall contain a function
  57. main.  It does say that "the function called at program startup is named
  58. main", but is rather silent about what happens if no such function
  59. exists.  (Such silences are generally interpreted as undefined behavior.)
  60.  
  61. There are other differences as well: if it exists, the function main may
  62. only have one of two forms.  Unlike in C++, there is no implication that
  63. the implementation may permit other forms.
  64.  
  65. > James Kanze continues:
  66. > >I believe that the simple answer is that Windows programs operate in a
  67. > >unhosted environment.
  68. > That's a possible answer with regard to C conformance, but C++ is different:
  69. > C++ programs must contain main() even in an unhosted environment, according
  70. > to the September 95 draft C++ standard.  (The reason for this is because
  71. > the definition of the order of execution of constructors for global variables
  72. > is defined with reference to when main() gets invoked.)
  73.  
  74. Correct.  I just checked the definition of an unhosted environment, and
  75. it is far more restrictive than in C.  In fact, the only difference is
  76. that in an unhosted environment, most of the libraries may be missing.
  77.  
  78. > I'm not sure whether Windows C/C++ compilers claim conformance to the
  79. > relevant C/C++ standards.  One would need to consult the documentation
  80. > for the compiler in question to see whether they claimed conformance,
  81. > and if so, whether they claimed conformance as a hosted or unhosted
  82. > environment.  Even if they do claim conformance, they will usually have
  83. > some conforming and some non-conforming modes of operation; you need to
  84. > be sure that the compiler is being invoked in the correct mode.
  85.  
  86. This is true for most compilers, I believe.  (Even for those claiming
  87. compliance, the question arises: with which version of the draft.)
  88.  
  89. > >Another interesting point that was made in the discussion on
  90. > >comp.std.c was that g++ normally operates in an unhosted environment,
  91. > >at least according FSF.
  92. > That depends on what you mean by "normally".  If you have installed g++
  93. > together with the GNU C and C++ libraries, then I believe that the FSF
  94. > would claim conformance (modulo the odd bug here and there) as a hosted
  95. > environment, not just as an unhosted environment.  This is normally the
  96. > case on Linux, for example, although I agree that it is probably not
  97. > normally the case on most other systems.
  98.  
  99. Well, normally, for me, means on a Sun:-).  In fact, however, g++ is
  100. more compliant (in a hosted environment) than Sun CC, at least under Sun
  101. OS 4.1.  They may use the local libc, but at least they fixed up
  102. stdlib.h so that free takes a void*.  (It's obvious that Sun wants you
  103. to upgrade to Solaris.  Rather pissed me off, though.  I'd told every
  104. one at the customer site how great the Sun compiler was, and when they
  105. finally bought it, we couldn't even compiler our overloaded operator
  106. delete:-(.)
  107.  
  108. > >|> You are correct to infer that this means that all Windows programs
  109. > >|> which do not define main() are ill-formed.
  110. > >
  111. > >No, he's not.  They are simply programs for non-hosted environments.
  112. > No, I beg to differ -- as explained above, C++ requires main() even
  113. > for non-hosted environemnts.
  114.  
  115. Agreed.
  116.  
  117. Although one might ask what version of the draft (if any) they are
  118. trying to comply with.  My impression is that the intent is to be
  119. unhosted; until only a short time ago, however, the draft standard
  120. didn't even mention the word (and the wording implying the call to main
  121. in the initialization of statics is also very recent).
  122.  
  123. > >Whether requiring a different start-up procedure than calling main is
  124. > >a good idea for this extension can be discussed under quality of
  125. > >implementation; it is not a standards question, however.
  126. > Actually, I think it is, albeit not a direct one. Remember that the
  127. > purpose of the C++ standard is amoung other things to promote
  128. > portability of C++ programs.  Extensions should be done in a way that
  129. > makes it easy for customers to make selective use of them with
  130. > conditional compilation, so that they can easily write portable
  131. > programs that are nevertheless customized to take advantage of the
  132. > features of particular platforms.  Requiring a different start-up
  133. > procedure makes doing this more difficult than it need be.
  134.  
  135. The different start-up procedure is only required if you are using
  136. Windows (I think).  To use Windows, they also require you use a lot of
  137. other special functions, that you won't find on any other machine.
  138.  
  139. > >I personally think that the Microsoft environment stinks, but I still
  140. > >get the feeling that there is a double standard at work here. If
  141. > >someone complains that g++ doesn't issue a diagnostic when I define a
  142. > >nested function, dozens of people (including you, Fergus?) will
  143. > >quickly point out that all I have to do is add the flags -ansi
  144. > >-pedantic, and it will; without these flags, the compiler is operating
  145. > >in a non-conformant mode, and this fact is in the compiler
  146. > >documentation.  Unless things have changed in the last 4 years, you
  147. > >need to give a special flag to the compiler to get Windows support.
  148. > >The default mode was the conformant mode.
  149. > I don't think I am applying a double standard.
  150. > I did not claim that any or all Windows compilers were not conforming.
  151. > I simply pointed out what they were required to do in order to conform.
  152. > I did say that
  153. > | I think the problem is due to Microsoft overlooking the C and C++
  154. > | standards, not vice versa.
  155. > but the problem I was referring to was not that Microsoft's compilers
  156. > don't conform to the standard (most likely they do) but rather that
  157. > Microsoft encourages people to write non-portable, non-standard-conforming
  158. > code which is then subject to the usual problems of vendor lock-in.
  159.  
  160. This is probably true.  IBM used to do the same thing.  I suspect that
  161. a lot of other vendors would too, if they could get away with it.  (Will
  162. using Java lock you into Sun?  If not, I'm willing to bet that it is
  163. more because Sun's market would refuse to use it if this were the case,
  164. rather than any generosity on the part of Sun.)
  165.  
  166. > Now GNU's compilers also have their own extensions, and the problem of
  167. > vendor lock-in can also arise for programs that use GNU extensions, but
  168. > I do think GNU aims to minimize the difficulty of writing portable
  169. > programs that selectively take advantage of those additional features.
  170. > For example, the syntax of GNU's __attribute__ feature is designed to
  171. > make it easy to use a conditionally defined macro to enable/disable the
  172. > use of that feature.
  173.  
  174. Hmmm...  I believe in fact that the GNU coding guidelines actually
  175. encourages you to use GNU extensions in everything but the compiler
  176. itself (since it has to be compiled with the native C compiler).  At any
  177. rate, things like signatures and nested functions are turned on by
  178. default.  You need special switches to be compliant.
  179.  
  180. > >|> Windows compilers which wish to conform to the C and C++ standards
  181. > >|> should include code [...for WinMain()...]
  182. > >|> in their libraries, so that they can accept programs which define main()
  183. > >|> but not WinMain().
  184. > >
  185. > >And what will they do with all of the other Windows requests in the
  186. > >code?
  187. > They can do whatever they like.  I was reiterating the need
  188. > for Windows compilers to accept strictly conforming programs, and
  189. > showing how that could easily be implemented, in a way which made the
  190. > selective use of Windows features possible without the programmer
  191. > having to define WinMain(), even if the OS required a program to define
  192. > WinMain() rather than main().
  193.  
  194. Well, this was the case with the last Windows compiler I used (an early
  195. Zortech).  The use of WinMain was for programs which managed Windows
  196. themselves (and thus had a lot of calls to other proprietary routines).
  197. The compiler would happily compile normal programs, and run them from a
  198. shell within a window.  In practice, this is not much different from the
  199. situation with Unix and X.  An X-Windows program may have a function
  200. called main, but it has so many other things that aren't portable to
  201. other systems, it really doesn't matter.
  202. -- 
  203. James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
  204. GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
  205. Conseils, itudes et rialisations en logiciel orienti objet --
  206.               -- A la recherche d'une activiti dans une region francophone
  207. ---
  208. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  209.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  210.   in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  211.